IBIS Macromodel Task Group Meeting date: 06 August 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Ken Willis Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 30 meeting. Walter moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: Jitter HF/LF components: Michael Mirmak noted that the internal experts he would consult with for follow up responses to the questions from the previous meeting had not been available this week. He noted that he expects to have more information in the upcoming weeks. Other DDR5 topics: (Item #7 on the agenda) Arpad asked Randy and Michael M. if they had any new information to report for their AR to gather device manufacture input on these topics. Randy and Michael M. had nothing new to discuss. Walter moved that all of item #7 be added to the Tabled ARs: section, and he noted that we can untable it whenever we get new information. Michael M. seconded. No one opposed. (Note: The Tabled ARs: section already contained several distinct items for clock forwarding and DC_Offset). IBIS-ISS Parser discussion: Walter reviewed the "ISS Parser" email he had originally drafted for the IBIS Interconnect task group and had sent to ATM a few hours before the meeting. In it he broadly defined 4 levels of IBIS-ISS parsing we could consider. He noted up front that he thought we should only provide the simplest (Level 1) and could document that we don't provide the other three. Level 1 - Simply evaluate the syntax legality of each line independent of the rest of the circuit. This involves checking each line (including the + continuation characters) independently. The line is tokenized and checked to ensure it starts with a legal instance type (X, R, C, L, G, etc.), comment, or other valid token (.subckt, .include, .ends, etc.) from IBIS-ISS. Depending on the instance type, the parser would know which tokens are nodes, etc. Bob noted agreement but said that .param was a valid token missing from the list in the email. Walter agreed and noted that the email did not provide an exhaustive list but provided the broad framework. Level 2 - The parser could check any subcircuit hierarchy, and within the scope of .subckt/.ends it could generate a list of node names and frequency of occurrence. It could then report any nodes (other than global reference node) that appear only once. Walter noted that this level was an order of magnitude more difficult than Level 1. Level 3 - The parser could check to ensure that any filenames, subckt names, or model names that are referenced actually exist or are defined. (Note: Walter noted an error in his email. "Flatten all .include statements" was listed as an item in Level 3. In fact, this flattening should happen in Level 1 prior to the line-by-line syntax check.) Level 4 - The parser verifies full .subckt and model scoping rules. Walter reiterated that he thought we only need to provide Level 1. That would be sufficient to ensure that no subcircuit is using elements that aren't legal in IBIS-ISS. Additional checks provided by Levels 2 through 4 are nice, but we can expect whatever SPICE simulator an EDA tool or user relies on to catch those types of errors. Michael M. asked Walter what "level" he considered the ibischk parser. Walter said he would consider that at least a 4, but probably a 5 since ibischk will even check the I/V tables and waveforms in an IBIS Model for consistency. Mike L. noted that he agreed with Walter that Level 1 was a cost effective solution for IBIS-ISS parsing. He noted that if you were writing a Yacc grammar to do the parsing you could do a Level 1 parser and only write the base syntax, and it could check the file line-by-line without even storing anything beyond the line currently being processed. This would be low cost and provide all we need to flag the use of any non-IBIS-ISS constructs. Michael M. asked if checking for the presence (use) of reference nodes would have to be done at Level 2. Walter said no, it could be done at Level 1 and is shown in Level 1 in the email. Radek agreed that it could be done in level 1, and he noted that it's important to check for any use of the reference node. Bob noted that detecting use of Node 0 is okay, but it's not illegal to include Node 0, so it shouldn't be flagged as an error. The group discussed how an IBIS-ISS parser might be "integrated" with ibischk. Mike L. noted that IBIS Quality task group had been considering the introduction of two new command line options used to specify the IBIS-ISS and tschk parser executables. The consensus was that this was a reasonable approach. Arpad noted that it kept the ibischk, IBIS-ISS, and tschk parsers separate so they could be updated and released independently. Mike L. noted that he had originally envisioned a basic IBIS-ISS parser/checker embedded into ibischk, but since the existing tschk was already a stand-alone executable it made sense to handle the IBIS-ISS parser in a similar manner. Walter noted that the stand-alone tschk provides a syntax check, but it does not report on passivity, causality, etc. He suggested we might want to talk to someone on the IEEE P370 committee, which has done a lot of work with S-parameter metrics. They might have some checking routines we could include, and it would be helpful to the industry in general. Michael M. asked if that suggestion aligned with the results of the IBIS Touchstone Survey. Mike L. noted that the survey had asked questions about quality, and that one respondent had even mentioned IEEE P370. Bob noted that passivity is not a requirement and some Touchstone files used within IBIS could be active. Walter agreed that Touchstone files for on-die S-parameters (AMI - BIRD158) could be active, but he noted that for passive interconnect, packaging, etc. they should be passive. Walter noted that the parser could figure out from context whether a Touchstone file should be passive. Radek noted that some very useful checking that went beyond Level 1 would involve checking for the proper number of nodes in a subcircuit and ports in a Touchstone file. For example, we would want tschk to return the number of ports in the Touchstone file so it could be checked relative to the number of terminals in the including subcircuit. Walter agreed with Radek, but noted that whatever SPICE simulator was being used at simulation time could be expected to find and report those types of errors. The only thing we couldn't expect a general SPICE simulator to catch was whether the IBIS-ISS model used a device type outside the subset of SPICE device types included in IBIS-ISS. Bob noted that he had heard in the past that users really wanted a full (Level 4) IBIS-ISS parser. Walter roughly estimated that a basic Level 1 tokenizer and checker was on the order of weeks or a month to develop. He said anything for Level 2 or beyond was likely many months. Bob noted that the ibischk developer had once proposed developing a Level 4 IBIS-ISS parser by starting with the open source Berkley SPICE code. Walter proposed a straw poll on the choices. Arpad asked if we had concluded we wanted an IBIS-ISS parser at all. Mike L. suggested voting on whether Level 1 and Level 4 were worth considering. He noted that the differences in effort between 2, 3 and 4 weren't that important relative to the big jump from Level 1 to Level 2. Walter moved for an acclamation vote on whether ATM thought it was worthwhile to provide a Level 1 IBIS-ISS parser. Bob seconded. There were no objections, so it was unanimous that we should consider having a Level 1 parser developed. Bob moved for a roll call vote on whether it was worthwhile to provide a Level 4 IBIS-ISS parser. Walter seconded. The vote was: ANSYS - No Intel - Yes Keysight - Abstain Mentor - Yes Micron - Yes SiSoft - No Teraspeed Labs - Yes Yes (4), No (2), Abstain (1). Since a majority voted in favor, we plan to ask the ibischk developer for a quote on a Level 4 IBIS-ISS parser. Walter said the conclusion from the two votes was that we should get quotes for Level 1 and Level 4 IBIS-ISS parsers. Arpad asked how this information should be reported to the Open Forum. Walter and Randy said Arpad could simply mention it in the ATM task group update at the Open Forum meeting. Curtis noted that the IBIS Quality task group (Bob in particular) usually interacts with the ibischk parser developer. Bob noted that we would start with informal quotes from the parser developer on Level 1 and Level 4 IBIS-ISS parsers, and that he would wait until ibischk 7.0 was complete before asking for the IBIS-ISS quotes at all. - Michael M.: Motion to adjourn. - Mike L.: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 13 August 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives